Este README.md tiene como objectivo dar el detalle de la implementación realizada con un cluster de Cassandra 3.11, montado en docker, python 3.10 para la comunicación y automatización de procesos, y Dbeaver como entorno de trabajo de Cassandra.
El alcance de este trabajo se resume a continuación:


Consultas a satisfacer
Consultas a satisfacer
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| paciente_nombre | text | Partition Key | Se utiliza paciente_nombre como clave de partición porque se usará para realizar búsquedas por nombre. |
| paciente_dni | int | Clustering Key | El DNI se usa como clustering key para garantizar que cada paciente tenga un identificador único dentro de la partición. |
| paciente_fecha_nac | date | ||
| paciente_direccion | text | ||
| paciente_tlf | text | ||
| paciente_alergias | SET |
Consultas a satisfacer
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| medico_dni | int | Partition Key | medico_dni se utiliza como clave de partición porque la consulta más común será obtener las citas de un médico específico. |
| cita_id | int | Clustering Key | cita_id se usa como clave de agrupamiento para ordenar las citas de un mismo médico. |
| cita_fecha_hora | timestamp | ||
| cita_motivo | text |
Consultas a satisfacer
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| paciente_dni | int | Partition Key | paciente_dni es la clave de partición porque las consultas se realizan sobre el DNI del paciente. |
| cita_id | int | Clustering Key | Se usa cita_id como clustering key para agrupar los tratamientos por cita. |
| tratamiento_id | int | Clustering Key | Se añade tratamiento_id para ordenar los tratamientos dentro de una misma cita. |
| tratamiento_descripcion | text | ||
| tratamiento_costo | float |
Consultas a satisfacer
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| paciente_dni | int | Partition Key | paciente_dni es la clave de partición porque se desea realizar consultas para un paciente específico. |
| cita_id | counter | Se utiliza un contador para registrar la cantidad de citas de un paciente. |
Consultas a satisfacer
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| receta_fecha_emision | date | Partition Key | receta_fecha_emision se utiliza como clave de partición para facilitar las consultas por fecha de emisión de recetas. |
| receta_id | int | Clustering Key | receta_id se utiliza como clustering key para ordenar los medicamentos dentro de cada receta. |
| medicamento_codigo | int | Clustering Key | Se añade medicamento_codigo para mantener un orden dentro de cada receta. |
| medicamento_nombre | text | ||
| medicamento_dosis | text |
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| tarjeta_banco | text | Partition Key | El banco emisor de la tarjeta actúa como partition key para agrupar todas las reservas realizadas con tarjetas de un banco específico. |
| tarjeta_nro | bigint | Clustering Key | El número de la tarjeta se utiliza como primera clustering key para ordenar las reservas dentro de un banco, garantizando la unicidad de las tarjetas. Se cambia a bigint dado que los números de tarjetas suelen ser largos. |
| reservacion_nro | text | Clustering Key | El número de reservación se utiliza como segunda clustering key para garantizar unicidad. |
| reservacion_confirmado | boolean | Se añade para saber si la reserva esta confirmada o no. |
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| pelicula_categoria | text | Partition Key | La categoría de la película forma parte de la partition key compuesta, utilizada para agrupar películas por categoría y actor específico. |
| pelicula_actor | text | Partition Key | El actor de la película forma parte de la partition key compuesta, permitiendo agrupar todas las películas en las que participa un actor específico dentro de una categoría. Esta se añade por el hecho que las categorias estan mayormente en un valor en particular, lo cual no es algo deseado para la llave de partición. |
| pelicula_nombre | text | Clustering Key | El nombre de la película se utiliza como clustering key para ordenar las películas alfabéticamente dentro de cada categoría y actor, y asegurar unicidad. |
| pelicula_actores | set |
Se adiciona un registro por cada actor. |
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| usuario_tlf | text | Partition Key | El teléfono del usuario actúa como partition key, ideal para buscar usuarios por un número de teléfono específico. |
| usuario_dni | text | Clustering Key | El DNI del usuario se utiliza como clustering key, permitiendo ordenar los usuarios dentro de cada número de teléfono. |
| usuario_nombre | text | ||
| usuario_tlfs | set |
Se adiciona un registro por cada telefono |
| Nombre del Campo | Tipo | Primary Key | Comentario |
|---|---|---|---|
| ciudad_nombre | text | Partition Key | El nombre de la ciudad actúa como partition key, utilizado para agrupar funciones por ciudad. |
| pelicula_nombre | text | Clustering Key | El nombre de la película se utiliza como primera clustering key, permitiendo ordenar las funciones dentro de cada ciudad por película. |
| funcion_fecha_hora | timestamp | Clustering Key | La fecha y hora de la función se utilizan como segunda clustering key, organizando cronológicamente las funciones para cada película dentro de una ciudad. Se añade como timestamp dado que las funciones contiene fecha y hora. |
Además, cabe destacar que para poder generar las operaciones CRUD no solo se conto con las tablas descritas anteriormente para el modelo lógico, sino que además se añadieron tablas de relaciones, y soporte. También, se expone que para la visualización del tablero, y evidenciación de que las operaciones funcionan correctamente se realizan consultas ineficientes, esto para facilicitar la visualización del lector.
A continuación se muestran las tablas resultantes desde DBeaver:

Las funcionalidades que se presentan están separadas por scripts de python para aislar los tipos de funcionalidades, y facilitar un poco la lectura del código. Entre las caracteristicas particulas a denotar están:
./crud/inserts.py, /crud/deletes.py, /crud/selects.py, /crud/updates.py) dentro de la carpeta ./crud. Cada archivo contiene una clase con las operaciones disponibles./crud/utils.py llamada queryStringTemplates que estandariza las sentencias CQL a Cassandra./crud/precarga_datos.py que contiene ejemplos sinteticos para poder validar el funcionamiento del sistema, y el modelo lógico.pip install poetry. Active el entorno con poetry shell, e instale dependencias con poetry install --no-root.python menu.py par iniciar con esta opción.streamlit run tablero_consultas.pyA continuación se muestran pantallazos de como lucen ambas interfaces. Mayormente me centrare en el tablero porque es más limpio visualmente de mostrar, sin embargo, queda a libre revisión la opción por terminal.

Note que hay dos botones para poder cargar datos de prueba, y limpiar todos los datos de las tablas. En todas las páginas se encuentran estos botones.































La clase select es la más amplia, ya que ofrece una gran variedad de consultas. Por simplicidad, solo mostrare una de ellas acá, pero la lógica es muy similar para las demás.
